Extended results of Tornado: A Run-Fail-Grow approach for Dynamic Application Tayloring

Producing a small deployment version of an application is a challenge because static abstractions such as packages cannot anticipate the use of their parts. As such, an application often occupies more memory than ac- tually needed. To solve this problem we propose Tornado, a technique to dynamically tailor applications to only embed code (classes and methods) they use. Tornado uses a run-fail-grow approach to prepare an application for deployment. It launches minimal version of an application and installs a minimal set of statements that will start the user's application. This ap- plication is run and these statements are executed. When the application fails because there are classes or methods missing, the necessary code is installed. The application is executed until it reaches a stable point, allow- ing possibly human interaction for applications with UIs. Thus, Tornado creates minimal memory footprint versions of applications by tailoring the whole application's code, including run-time and third party libraries. We used Tornado to tailor two different applications. We succeeded to tailor a hello world application to occupy 1% of its original size. We also experimented with a Seaside web application tailoring in one case only the application's and framework's code and the whole application's code in the other case. In this latter example, we reached memory savings of about 97%. In this report we present an overview on Tornado, and we give details of the results we obtained

Virtual Smalltalk Images: Model and Applications

International audienceReflective architectures are a powerful solution for code browsing, debugging or in-language process handling. However, these reflective architectures show some limitations in edge cases of self-modification and self-monitoring. Modifying the modifier process or monitoring the monitor process in a reflective system alters the system itself, leading to the impossibility to perform some of those tasks properly. In this paper we analyze the problems of reflective architectures in the context of image based object-oriented languages and solve them by providing a first-class representation of an image: a virtualized image. We present Oz, our virtual image solution. In Oz, a virtual image is represented by an object space. Through an object space, an image can manipulate the internal structure and control the execution of other images. An Oz object space allows one to introspect and modify execution information such as processes, contexts, existing classes and objects. We show how Oz solves the edge cases of reflective architectures by adding a third participant, and thus, removing the selfmodification and self-observation constraints

Understanding Pharo's global state to move programs through time and space

International audienceCode mobility is a mechanism that allows the migration of running programs between different environments. Such migration includes amongst others the migration of application data and resources. Application's data is is usually composed by elements of different nature: from printers and files, to framework and domain objects. This application data will be transported along with the code of its program in space (when serialized and deployed in another environment) or time (when a new session is started in a different point of time). The main problem when moving around code resides, in our understanding, to global state. While unreferenced leaf objects are garbage collected, those referenced (transitively) by some global object will remain alive. In order to support code mobility in time and space, we need to understand how global application data is used. With this purpose, we study and classify Pharo's global state. This classification uncovers some common patterns and provides a first insight on how global state should be managed, specially in code mobility scenarios. As a minor contribution, we also discuss solutions to each of the found categories

Object Swapping Challenges: an Evaluation of ImageSegment

International audienceIn object-oriented systems, runtime memory is composed of an object graph in which objects refer to other objects. This graph of objects evolves while the system is running. Graph exporting and swapping are two important object graph operations. Exporting refers to copying the graph to some other memory so that it can be loaded by another system. Swapping refers to moving the graph to a secondary memory (for example, a hard disk) to temporary release part of the primary memory (for example, RAM). Exporting and swapping are achieved in different ways and the speed in presence of large object graphs is critical. Nevertheless, most of the existing solutions do not address well this issue. Another challenge is to deal with common situations where objects outside the exported/swapped graph point to objects inside the graph. To correctly load back an exported subgraph, it is necessary to compute and export extra information that is not explicit in the object subgraph. This extra information is needed because certain objects may require to be reinitialized or recreated, to run specific code before or after the loading, to be updated to a new class definition, etc. In this paper, we present all general problems to our knowledge about object exporting and swapping. As a case of study, we present an analysis of ImageSegment, a fast solution to export and swap object graphs, developed by Dan Ingalls. ImageSegment addresses the speed problems in an efficient way, as shown by the results of several benchmarks we have conducted using Pharo Smalltalk. However, ImageSegment is not a panacea since it still has other problems that hampers its general use

Towards Structural Decomposition of Reflection with Mirrors

International audienceMirrors are meta-level entities introduced to decouple reflection from the base-level system. Current mirror-based systems focus on functional decomposition of reflection. In this paper we advocate that mirrors should also address structural decomposition. Mirrors should not only be the entry points of reflective behavior but also be the storage entities of meta-information. This decomposition can help resolve issues in terms of resource constraints (e.g. embedded systems and robotics) or security. Indeed, structural decomposition enables discarding meta-information

Mercury: a Model for Live Remote Debugging in Reflective Languages

Remote debugging facilities are a technical necessity for devices that have limited computing power to run an IDE (e.g., smartphones), lack appropriate input/output interfaces (display, keyboard, mouse) for programming (e.g mobile robots) or are simply unreachable for local development (e.g cloud-servers). Yet remote debugging solutions can prove awkward to use due to their distributed nature. Empirical studies show us that on average 10.5 minutes per coding hour (over five 40-hour work weeks per year) are spend for re-deploying applications while fixing bugs or improving functionality. Moreover current solutions lack facilities that would otherwise be available in a local setting because its difficult to reproduce them remotely. Our work identifies three desirable properties that an ideal solution for remote debugging should exhibit, namely: run-time evolution, semantic instrumentation and adaptable distribution. Given these properties we propose and validate Mercury, a live remote debugging model and architecture for reflective OO languages

Visualizing Objects and Memory Usage

International audienceMost of the current garbage collector implementations work by reachability. This means they only take care of the objects that nobody else points to. As a consequence, there are objects which are not really used but are not garbage collected because they are still referenced. Such unused but reachable objects create memory leaks. This is a problem because applications use much more memory than what is actually needed. In addition, they may get slower and crash. It is important to understand which parts of the system are instantiated but also which are used or unused. There is a plethora of work on runtime information or class instantiation visualizations but none of them show whether instances are actually used. Such information is important to identify memory leaks. In this paper, we present some visualizations that show used/unused objects in object-oriented applications. For this, we use Distribution Map which is a visualization showing spread and focus of properties across systems. We extend Distribution Maps to represent the way classes are used or not, since we distinguish between a class that just has instances from one that has used instances. To identify unused objects, we modified the Pharo Virtual Machine

Problems and Challenges when Building a Manager for Unused Objects

International audienceLarge object-oriented applications may occupy hundreds of megabytes or even gigabytes of memory. During program execution, a large graph of objects is created and constantly changed. Most object runtimes support some kind of automatic memory management based on garbage collectors (GC) whose idea is the automatic destruction of unreferenced objects. However, there are referenced objects which are not used for a long period of time or that are used just once. These are not garbage-collected because they are still reachable and might be used in the future. Due to these unused objects, applications use much more resources than they actually need. In this paper we present the challenges and possible approaches towards an unused object manager for Pharo. The goal is to use less memory by swapping out the unused objects to secondary memory and only leaving in primary memory only those objects which are needed and used. When one of the unused objects is needed, it is brought back into primary memory

Marea: An Efficient Application-Level Object Graph Swapper

International audienceAbstract During the execution of object-oriented applications, several millions of objects are created, used and then collected if they are not referenced. Prob- lems appear when objects are unused but cannot be garbage-collected because they are still referenced from other objects. This is an issue because those ob- jects waste primary memory and applications use more primary memory than they actually need. We claim that relying on the operating system's (OS) virtual memory is not always enough since it cannot take into account the domain and structure of applications. At the same time, applications have no easy way to parametrize nor cooperate with memory management. In this paper, we present Marea, an efficient application-level object graph swapper for object-oriented programming languages. Its main goal is to offer the programmer a novel so- lution to handle application-level memory. Developers can instruct our system to release primary memory by swapping out unused yet referenced objects to secondary memory. Our approach has been qualitatively and quantitatively val- idated. Our experiments and benchmarks on real-world applications show that Marea can reduce the memory footprint between 23% and 36%

Problems and Challenges when Building a Manager for Unused Objects

International audienceLarge object-oriented applications may occupy hundreds of megabytes or even gigabytes of memory. During program execution, a large graph of objects is created and constantly changed. Most object runtimes support some kind of automatic memory management based on garbage collectors (GC) whose idea is the automatic destruction of unreferenced objects. However, there are referenced objects which are not used for a long period of time or that are used just once. These are not garbage-collected because they are still reachable and might be used in the future. Due to these unused objects, applications use much more resources than they actually need. In this paper we present the challenges and possible approaches towards an unused object manager for Pharo. The goal is to use less memory by swapping out the unused objects to secondary memory and only leaving in primary memory only those objects which are needed and used. When one of the unused objects is needed, it is brought back into primary memory